2017年软件质量和测试大盘点
十天前，2017年12月22日，比特币价格跌破12,000美元，几天就跌去了将近7000美元（比其最高点下跌了约40%）。与此同时，大规模抛售导致备数字货币交易平台Coinbase出现短暂宕机——从美国东部时间9:30到10点用户无法访问该交易平台、网站显示处于离线状态。11点之后不久，Coinbase宣布已经暂停了部分交易并在官方网站上表示：“由于高网络流量，买卖功能可能临时下线。我们正在努力恢复全部功能。”
...... (此处省去几万字)
2017年3月21日晚上7点左右，有ofo用户反映在输入车辆号码后，App提示“系统内部错误”，无法解锁车辆，而这仅仅在ofo宣布订单过千万之后的五小时，ofo宕机了，小黄车骑不了了。（参见：http://www.bj.xinhuanet.com/bjyw/2017-03/22/c_1120675797.htm ）
2017年3月9 新华社转发了“中国军网”的文章：全军武器装备采购信息网宕机因为啥 （http://news.xinhuanet.com/mil/2017-03/09/c_129505763.htm ）
2017年2月28日晚9点，百度移动端宕机了，前后大约42分钟。用户使用百度移动搜索时，无论使用任何关键词进行搜索，都会提示“很抱歉，您要访问的页面不存在！”……在百度官方自媒体上，被调侃为“不正经”（“大家一直用的搜索引擎”不正经了一小会儿，很抱歉！ ）初步分析的结果是，宕机事件是由于百度公司的软件更新中存在Bug（漏洞），导致了服务器停止服务。对于此次事件，工信部很关注，要求百度深入调查，提出整改措施，在 3 日内向工信部递交书面报告。（参见：http://www.sohu.com/a/127672285_115161 ）
几乎是同一天， 亚马逊云（Amazon S3 Cloud ）出现严重的宕机（中断服务）！亚马逊云之前也出现过宕机，但一般在一个小时之内解决问题，而这次非常严重，宕机整整四个小时，其原因居然是某工程师做了一个简单操作（一个简单的误操作可以毁灭互联网？ ）。
2017年1月31日，GitLab.com的一个数据库发生了灾难性的事故——丢失了6个小时的数据 （不得不谈谈农历新年首次质量大事故：GitLab丢失数据 ）。
这样的故事太多了，可以看看下面几张图，综合起来，当前软件（系统或服务）的质量堪忧。
回顾2017年软件质量和测试时，我们从质量事故说起，主要是想让大家关注质量，因为今天软件无处不在，甚至有一天“软件定义世界”，软件质量已经关系到我们的生活和安全。但是，有些领导“不见棺材不流泪”，不出质量事故就不重视软件质量与测试。有时候明显感到管理层不重视质量，但无可奈何，只能等出了质量大事故，他们才重视（现实悲剧）。
在今天敏捷开发模式盛行的情况下，质量更加堪忧，不是敏捷的问题，而是国内研发人员在质量意识与文化、责任心和能力等多个方面还存在较大问题。在今年所进行的 敏捷测试现状调查 就显示质量意识弱、自动化测试率低、缺乏良好的过程能力和协作能力等。敏捷开发高不好，往往是价值观、思维方式和态度问题，例如 实现自动化测试，首先不是一个技术问题。在这些方面与国外先进的公司差距还较大，技术差距还不大。2017年在这些方面没有多大改进，虽然我们追随微软、谷歌等公司的软件工程之道（Google公司的软件工程之道 ）有很多年了，往往学的是形式，做得形似而非神似。 当我们敏捷开发和敏捷测试（如CI/CD）还没有做好之时，DevOps已经兴起 ，大数据、物联网等会使问题复杂性大大增强，这些很可能会增加大量的软件质量风险。我们又必须接受软件质量的新挑战，迫使我们从各方面做好工作，包括质量文化、人员素质和能力、流程、技术和工具。例如，对大多数软件公司常常对国家/国际标准熟视无睹，虽然ISO和国家标准化管理委员会发布了上百个标准。2017年发布了比较多的标准，其中有几个标准还值得大家关注，例如：
ISO/IEC TS 25011:2017 信息技术系统与软件质量要求和评价(SQuaRE) 服务质量模型
GB/T 25000:12-2017 信息技术系统与软件质量要求和评价(SQuaRE) 第12部分数据质量模型
GB/T 25000:24-2017 信息技术系统与软件质量要求和评价(SQuaRE) 第24部分数据质量测量
GB/T 34943-2017 C/C++语言源代码漏洞测试规范
GB/T 34944-2017 Java语言源代码漏洞测试规范
GB/T 34946-2017 C#语言源代码漏洞测试规范
以后就标准、价值观、质量文化等展开务虚讨论，下面务实——侧重回顾2017年软件测试技术和工具新动态（相对2016年），从其侧面可以体会软件测试的发展趋势。
这几年，人们非常关注自动化测试，国内招“测试开发”职位猛增。在自动化测试中，更关注API的自动化测试，不管是SDK、webservice的测试还是微服务的测试，都加强了API的自动化测试，将 API 当做产品（APIs as a product），即使 API消费者是企业内部的系统或开发人员。易用性测试(Usability testing) 不仅适合系统的应用，也适合API的测试，将产品思维带入到 API中，更好地理解API的使用模式，从而得到更好的 API 设计。
从国内技术会议，大家也可以感觉，过去一年大家更关注基于容器技术的测试环境建设、大数据与云服务平台的测试、移动应用和敏捷测试的深入等，例如可以看到下列这样类似主题的分享：
基于容器的持续集成平台建设和应用
构建于Kubernetes上的微服务持续集成与质量保证
DevOps自动化测试
基于云的规模化测试实践
云质量平台的演进
大数据并发场景下的性能测试
大数据平台测试
基于BDD端到端的自动化测试
ET从抗拒到深入人心
iOS UI自动化+基于docker的分布式执行
1. 测试基础设施
软件测试基础设施（Infrastructure）在CI/CD、DevOps实践中越来越重要。在软件部署到生产环境之前维护一个系统集成测试环境（System Integration Testing ，SIT ）是非常有必要的，而这常常成为持续交付的瓶颈。环境本身很脆弱而且维护成本很高（如手动配置），在SIT环境的测试给出的反馈慢且不可靠。其中涉及到一些重要的技术包括契约测试、将发布与部署解耦、基础设施即代码（Infrastructure as code，IaC）
对IaC进行自动化测试还没有被广泛理解，但在2017年得到更多关注。CI和CD工具可以用来测试服务配置（如Chef的cookbook，Puppet的模块，Ansible的playbook）、服务镜像构建（如Packer）、环境准备（Terraform，CloudFormation等）以及环境的集成。对IaC使用流水线可以让错误在进入研发、运维环境之前就能被发现。
Tool | Released by | Method | Approach | Written in |
Ansible Tower | Ansible (RedHat) | Push | Declarative and imperative | Python |
CFEngine | CFEngine | Pull | Declarative | - |
Chef | Chef | Pull | Imperative | Ruby |
Otter | Inedo | Push | Declarative and imperative | - |
Puppet | Puppet | Pull | Declarative | Ruby |
SaltStack | SaltStack | Push and Pull | Declarative and imperative | Python |
Kubernetes已经成为主流公有云平台（如微软Azure 容器服务、 Google Cloud）上的首选容器编排平台，而且人们还在不断为Kubernetes产品，不断丰富快速扩大的Kubernetes生态圈
Heptio Sonobouy（https://github.com/heptio/sonobuoy）是一个以非破坏性的方式在任何Kubernetes群集上运行端到端“合规性测试”的诊断工具：
集成了端到端(e2e) conformance-testing 1.7+
客户数据收集、负载诊断
它可以成为IaC的一部分，以确保各种Kubernetes发行版和配置都符合最佳实践，同时遵循开源标准化原则以实现集群互操作性，以验证整个集群的行为和健康状况。
Molecule（https://github.com/metacloud/molecule） 旨在帮助开发和测试 Ansible 角色（https://docs.ansible.com ），如Ansible 语法静态检查、幂等性测试和收敛性测试，并能够利用 Vagrant 、 Docker 和 OpenStack 来管理虚拟机或容器，并支持 Serverspec 、 Testinfra 或 Goss 来运行测试。
Testinfra（http://testinfra.readthedocs.io/en/latest/index.html）可以方便地测试服务器的实际状态，其目标是成为 Serverspec （用于编写RSpec测试来检查服务器配置是否正确，通过SSH、WinRM、Docker API等执行命令来测试服务器的实际状态，不需要在服务器上安装任何代理软件。它可以使用任何配置管理工具，如Puppet，Ansible，CFEngine，Itamae等）在Python中的等价物，并且作为 Pytest测试引擎的插件来使用
2. 单元测试
AssertJ（http://joel-costigliola.github.io/assertj/index.html）是一个提供流式断言接口的Java库（其口号：Fluent assertions for java），可以代替代替JUnit和Hamcrest组合，主要亮点有：
在代码完成之时通过IDE配置得到assertThat
用as描述断言（String 描述，Object ... args）
在迭代器或数组上将过滤和断言结合起来
针对提取的迭代器/数组元素的属性设置断言
针对迭代器/数组元素方法调用的结果设置断言
收集软断言的所有错误信息
针对文件的内容使用String断言
异常断言指南
在断言中可以使用自定义比较策略
按字段逐项比较
…..
CSS IN JS是一种用JavaScript编写CSS样式的技术，使样式和逻辑的关注点得到统一。styled-components很适合像React这样基于组件的框架，并且可以使用jest-styledcomponents做CSS的单元测试
3. 前端测试
Headless Chrome 非常适合执行那些依赖浏览器的前端测试，正在迅速取代那种用 JavaScript 驱动 WebKit 引擎的方法（如 PhantomJS），因为Headless Chrome运行速度要快得多，在行为上更贴近真实的浏览器，但它要占用更多内存。 基于上述优点，针对前端测试的HEADLESS CHROME 很可能成为这个领域的事实标准。
Lighthouse （https://github.com/GoogleChrome/lighthouse）分析web应用及其页面, 收集性能测试数据、洞察开发人员的最佳实践
NightWatch（http://nightwatchjs.org）：基于Node.js的验收测试框架，使用流畅的 API 定义测试，然后在Selenium / WebDriver 服务器上执行。它采用简单的语法来编写端到端的测试脚本，还支持使用JavaScript和CSS选择器。之前的工具，如Selenium使用其WebDriver API、PhantomJS使用无界面的WebKit浏览器。与Nightwatch相比，Selenium和PhantomJS语法冗长，且不支持从命令行中进行开箱即用的持续集成。2014年就有文章介绍NightWatch（http://www.infoq.com/cn/news/2014/02/nightwatch ），下面是其主要特性：
Jest（http://facebook.github.io/jest/）是一个“零配置”的前端测试工具，如Mock和代码覆盖之类的开箱即用特性，主要用于React和其他JavaScript框架，其快照测试（Snapshot Testing）可以作为测试金字塔上层一个很好的补充。Jest主要优势：
高速和沙盒：Jest 跨workers并行的测试运行以达到性能最大化。沙盒测试文件和自动全局状态将为每个测试重置，因此任何两个测试间不会冲突。
内置代码覆盖率报告：使用 --coverage 参数来轻松地创建代码覆盖率报告。无需安装额外的程序或代码库 ！Jest 可以从整个项目（包括未经测试的文件）收集代码覆盖率信息。
零配置：在使用 create-react-app 或 react-native init 创建React 或 React Native 项目时，Jest 都已经配置好。在 __tests__文件夹下放置测试脚本，或者使用 .spec.js 或 .test.js 后缀命名脚本文件
功能强大的Mock代码库，使用 jest-react-native来模拟React Native组件。
CyPress不仅是一个测试框架，更是一个强大的测试平台，它能帮助开发人员轻易地构建端到端自动化测试，并且把测试的步骤录制在一个 MP4 文件里。
4. 契约测试
Spring Cloud Contract（https://cloud.spring.io/spring-cloud-static/spring-cloud-contract/1.0.0.RELEASE）来进行消费者驱动的契约测试，以根据契约来验证客户端的调用以及服务器端的实现。与Pact（开源的消费者驱动契约测试工具集）相比，它不支持契约代理，也不支持其它编程语言。不过，它能与Spring生态系统完美集成，如使用Spring Integration进行消息路由。Spring Cloud Contract 包含三个项目：
Spring Cloud Contract Verifier
Spring Cloud Contract WireMock
Spring Cloud Contract RestDocs
Truffle（http://truffleframework.com）是一个为以太坊（Ethereum）设计的开发框架——“YOUR ETHEREUM SWISS ARMY KNIFE”，接管了智能合约编译、库链接和部署，以及在不同区块链网络中处理制品的工作。鼓励开发者为智能合约编写测试，这得益于其内置的测试框架以及与Test RPC 的集成，Truffle 可以允许我们使用 TDD 的方式来编写智能合约。
5. 移动测试
AWS Device Farm (https://aws.amazon.com/cn/device-farm/ ,前1000分钟免费)提供移动应用测试服务，可以让Android、iOS 和 Web 应用同时运行在各种物理设备上，并与应用程序进行交互它会在每次应用运行期间生成相似的日志，性能图标和屏幕截图，以及提供常规和特定设备的反馈。该服务为用户提供了很大的灵活性，允许改变每个设备的状态和配置，以便重现一些非常特定的测试场景。
6. 性能测试
随着Gatling和Locust等工具的日益成熟，压力测试变得越来越容易，不要再花冤枉钱去买LoadRunner。FLOOD IO是一个基于SaaS的压力测试服务。它可以用来向数百台云端服务器分发测试脚本并在其上执行。通过重用现有的Gatling测试脚本能很简单地将性能测试迁移到Flood IO。
7. 安全性测试
Inspec 是受 Serverspec （上面有介绍）启发而开发出来的基础架构测试工具，更适合需要确保数以千计的服务器的合规的安全专家使用。各个测试可以组合成完整的安全配置文件，并支持命令行远程运行，也适合生产环境的安全性测试。
了解测试这些领域的变化，或许能为我们2018年的学习指明了方向，或许对我们做好2018年测试工作有帮助。
最后，祝大家新年快乐！事业有成！